

Salut !

L'AMS plante en bouclant au milieu d'une criture en Flash invalide.
Elle est effectue dans la fonction du trap #11 qui nettoie la Flash
au reset : la limite suprieure de la Flash (FlashMemoryEnd), qui est
calcule dynamiquement uniquement sur Titanium, a t mal calcule, et
l'criture essaie d'aller trop loin en mmoire.

Le calcul dynamique de la taille de la FlashROM est effectu avant par
une autre fonction du trap #11, ajoute spcialement sur l'AMS 3.00 de
la Titanium. J'ai document a dans ma doc sur la Titanium
(commentaire 2). Il semble que des futurs modles pourrait avoir 8Mo
de Flash, ou alors ce serait pour garder une compatibilit du code
avec la TI-89, je ne sais pas trop.

En tout cas voil ce qu'il faut que tu implmentes sur TiEmu pour
viter le problme : des commandes sont envoyes  la mmoire Flash
pour dterminer sur quel modle on se trouve, voil le bout de code de
l'AMS correspondant :

lea CertMem,a1 ; Any valid address within the device (= the EEPROM
chip). Sur TI, semble devoir tre CertMem absolument (?)
move.w #$9090,(a1) ; Read Identifier Codes
move.w ROM_BASE,d1 ; Identifier code address + 0 -> Manufacturer Code
move.w ROM_BASE+2,d2 ; Bottom parameter device code
move.l #$400000,d0
cmp.w #$89,d1      ; Manufacturer Code
beq Ret
cmp.w #$B5,d2      ;  Bottom parameter device code
beq Ret
move.l #$800000,d0
Ret:
move.w #$5050,(a1) ; Clear Status Register
move.w #$FFFF,(a1) ; Read Array
move.l d0,d1
addi.l #ROM_BASE,d1
move.l d1,a0

Il faut donc que lorsque la commande 0x9090 est envoye  ROM_BASE +
0x10000,  le manufacturer code retourn  la lecture de ROM_BASE.w
soit 0x89 (le bottom parameter device code, $B5 n'a pas besoin d'tre
bon puisque le test fait est un OU, mais tu peux l'implmenter si tu
veux).

Tu peux avoir plus de dtail sur ces commandes en lisant la datasheet
de la FlashROM de la V200, car le mme type semble tre utilis sur la
Titanium.
Note que le manufacturer code de la V200 est 0xB0. Je ne connais pas
son bottom parameter device code.

Il semble y avoir un autre problme plus loin dans le code du reset,
mais comme  chaque que la calc est resete je dois rentrer moi-mme 
la main les variables de l'AMS mal fixes  cause du bug prcdent, et
que TiEmu crash bizarrement parfois lorsque j'appuie sur 'stop' du
dbogueur alors que on est en mode 'run', j'ai du mal  voir le
problme. Ce serait plus simple que du fasse un nouveau build avec ce
premier problme corrig.

Quelques autres remarques :

* La fentre Memory n'est pas toujours rafrachie. Il y a le bouton
refresh, mais on ne pense pas toujours  l'utiliser. Elle n'est pas
rafrachie notamment lorsque un breakpoint est touch, ce serait
possible de forcer le rafrachissement  ce moment l ?

* Pour le problme de scroll d'instructions gnant dont je te parlais
: va n'importe o dans l'AMS o il y a des instructions valides,
scroll instruction par instruction vers le bas, tu verras que sur
certaines instructions le scroll est effectu en haut, mais pas en bas
de la fentre (la dernire instruction reste la mme).

* Quelques ides pas forcment trs urgentes mais qui seraient
intressantes  implmenter :
- L'AMS utilise le registre a6 comme frame pointer, et accde
relativement  ce registre aux variables locales cres et aux
paramtres de la fonction excute.
Le problme est qu'avec des instructions de type cmp.w -$54(a6),d0, on
voudrait savoir ce qu'il y a  la variable  l'offset $54 : il faut
alors sortir une calculatrice hexa, calculer l'adresse relle et aller
dans la fentre Memory trouver la valeur.
L'idal serait d'avoir dans la mme fentre que stack frame, un memory
dumper qui ressemble  celui de la pile, mais avec les offsets
relatifs au registre a6 plutt que des adresses relles (offsets
positifs et ngatifs pour pouvoir regarder  la fois les variables
locales et les paramtres de la fonction). Par exemple :
-6  0084
-4  5600
-2  0000
0   0090
2   4924
4   2828
6   0000
Il faudrait que la fentre puisse tre scrollable  l'infini dans les
deux sens, on ne peut pas savoir la quantit de variables que la
fonction peut utiliser.
Si c'est trop compliquer  raliser, crire  ct de l'instruction
l'adresse correspondant  -$54(a6) dans l'exemple prcdent suffirait
pour pouvoir se dbrouiller, mais serait beaucoup moins bien.

- Un systme de breakpoint temporaire sur instruction, comme sous GDB,
serait pratique (breakpoint qui disparat la premire fois qu'il est
touch) : il m'arrive souvent de placer un breakpoint aprs un bsr ou
un jsr de l'AMS avant de faire un step into dans la sous-routine au
cas o elle serait trop profonde et que j'abandonne le dboguage 
quelques niveaux d'appels plus profond. Je fais un run et mon
breakpoint est touch; je l'enlve et je continue. Un breakpoint
temporaire viterait d'avoir  l'enlever  chaque fois.

++, bonne continuation,

-- Olivier
